Agentic AI mit dem Workflow Supervisor
Bei den bisherigen Architekturmustern hat immer ein Mensch oder eine feste Konfiguration entschieden was als nächstes passiert. Der Workflow Supervisor dreht das um: hier entscheidet eine KI.
Der Workflow Supervisor Agent ist ein KI-basierter Orchestrator. Er analysiert eine eingehende Aufgabe, wählt selbstständig aus einer Liste verfügbarer Workflows den oder die richtigen aus, führt sie in der von ihm als sinnvoll erkannten Reihenfolge aus und liefert am Ende eine zusammengefasste Antwort. Das ist echtes Agentic AI — autonom, iterativ, zielorientiert.
Was macht den Supervisor besonders?
Der Unterschied zu allen anderen Agenten in 42°OS ist fundamental: der Supervisor trifft Entscheidungen — nicht nur Berechnungen.
Ein Switch Agent verzweigt nach festen Regeln. Ein State Machine Agent folgt definierten Status-Übergängen. Der Supervisor hingegen bekommt ein Ziel und findet selbst den Weg — durch mehrere iterative LLM-Aufrufe, mit vollständigem Gedächtnis über den bisherigen Verlauf.
Das bedeutet: er kann mit unvorhergesehenen Eingaben umgehen, kann Workflows kombinieren die nie explizit verknüpft wurden, und kann auf das Ergebnis eines Workflows reagieren bevor er den nächsten aufruft.
Wie der Supervisor funktioniert
Der Ablauf ist iterativ:
Eingehende Nachricht (Aufgabe)
↓
LLM analysiert Aufgabe + verfügbare Workflows
↓
Entscheidung: welchen Workflow aufrufen?
↓
Workflow wird ausgeführt
↓
Ergebnis wird zur Konversationshistorie hinzugefügt
↓
LLM analysiert Ergebnis: weitere Schritte nötig?
↓
Ja → nächsten Workflow aufrufen
Nein → finale Antwort ausgeben
Der Supervisor führt diesen Zyklus so oft durch bis er entweder eine finale Antwort formuliert oder die maximale Anzahl an Iterationen (max_iterations) erreicht ist.
Konfiguration
Verfügbare Workflows als Tools
Der Supervisor kennt nur die Workflows die du ihm explizit als Tools zur Verfügung stellst. Im Agent-Editor wählst du sie per Dropdown aus und kannst optional eine Beschreibung hinzufügen — die erklärt der KI wofür der Workflow gedacht ist:
[
{
"workflow_id": 12,
"description": "Extrahiert strukturierte Daten aus einer PDF-Rechnung. Eingabe: Dateipfad.",
"input_schema": {
"type": "object",
"properties": {
"file_path": {"type": "string", "description": "Pfad zur PDF-Datei"}
},
"required": ["file_path"]
}
},
{
"workflow_id": 15,
"description": "Schreibt Rechnungsdaten ins ERP-System.",
"input_schema": {
"type": "object",
"properties": {
"invoice_data": {"type": "object"}
}
}
}
]
Je präziser die Beschreibung, desto besser die Entscheidungen der KI. Erkläre nicht nur was der Workflow tut, sondern wann er eingesetzt werden soll und welche Eingaben er erwartet.
Agent Goal
Das Agent Goal ist die wichtigste Konfigurationseinstelle — hier beschreibst du dem Supervisor in natürlicher Sprache was sein Ziel ist:
Du koordinierst die Verarbeitung eingehender Rechnungsdokumente.
Extrahiere zuerst die Daten aus dem Dokument, prüfe dann ob
alle Pflichtfelder vorhanden sind, und schreibe die Daten
abschließend ins ERP-System. Erstelle am Ende eine kurze
Zusammenfassung was verarbeitet wurde.
Das Agent Goal wird dem System-Prompt vorangestellt und kann jederzeit angepasst werden — auch wenn der System-Prompt selbst gesperrt ist.
Antwortender Agent
Pro Workflow kannst du festlegen welcher Agent die Antwort zurück an den Supervisor liefert. Das ist nützlich wenn ein Workflow mehrere Agents hat und nur die Ausgabe eines bestimmten (z. B. eines Zusammenfassungs-Agents) für den Supervisor relevant ist.
Ohne Konfiguration verwendet der Supervisor die letzte Nachricht im Workflow.
LLM-Einstellungen
| Option | Bedeutung | Empfehlung |
|---|---|---|
max_iterations | Maximale LLM-Zyklen | 5 für einfache, 10+ für komplexe Aufgaben |
timeout | Zeitlimit pro LLM-Anfrage in Sekunden | 180 Standard, bei komplexen Workflows erhöhen |
model | Genutztes LLM | gus:tav (Standard) |
Ausgabe des Supervisors
Der Supervisor liefert eine strukturierte Ausgabe:
{
"response": "Die Rechnung RE-2025-042 wurde erfolgreich verarbeitet.
Extrahierte Daten: Betrag 1.428,50 €, Lieferant: Mustermann GmbH.
Daten wurden ins ERP-System geschrieben.",
"iterations": [
{"iteration": 1, "decision": {"action": "call_workflow", "workflow": "PDF extrahieren"}},
{"iteration": 2, "decision": {"action": "call_workflow", "workflow": "ERP schreiben"}},
{"iteration": 3, "decision": {"action": "final"}}
],
"history": [...]
}
Das history-Feld enthält die vollständige Konversationshistorie — alle User-Nachrichten, LLM-Entscheidungen und Workflow-Ergebnisse. Das ist dein wichtigstes Debugging-Werkzeug: wenn der Supervisor eine unerwartete Entscheidung trifft, siehst du hier genau warum.
Sicherheitsfeatures
Prompt-Schutz
Der System-Prompt des Supervisors ist standardmäßig schreibgeschützt (allow_prompt_editing: false). Das verhindert versehentliche oder böswillige Änderungen an der Kernlogik des Orchestrators. Wenn du den System-Prompt anpassen musst, muss allow_prompt_editing explizit aktiviert werden.
Für die meisten Anpassungen reicht das Agent Goal — es wird dem System-Prompt vorangestellt und ist immer editierbar.
Praxisbeispiele
Beispiel 1: Ticket-Routing
Agent Goal:
Du routest eingehende Support-Anfragen an den richtigen Bereich.
Analysiere den Inhalt der Anfrage und leite sie an IT-Support,
HR oder Facility-Management weiter. Bestätige dem Absender
welcher Bereich die Anfrage übernimmt.
Verfügbare Workflows:
- "IT-Support Ticket erstellen"
- "HR-Anfrage verarbeiten"
- "Facility-Anfrage weiterleiten"
Beispiel 2: Mitarbeiter-Onboarding
Agent Goal:
Du koordinierst das Onboarding neuer Mitarbeiter. Erstelle
AD-Account, bestelle Hardware und sende die Willkommens-E-Mail.
Führe alle Schritte in der richtigen Reihenfolge aus und
fasse am Ende zusammen was erledigt wurde.
Verfügbare Workflows:
- "AD-Account erstellen" (input: name, department, start_date)
- "Hardware bestellen" (input: employee_name, equipment_type)
- "Willkommens-E-Mail senden" (input: email, name, start_date)
Wann Supervisor, wann State Machine?
Diese Frage stellt sich oft. Die Entscheidungshilfe:
| Kriterium | State Machine | Workflow Supervisor |
|---|---|---|
| Prozessschritte sind vorab bekannt | ✓ | – |
| Reihenfolge kann variieren, aber Möglichkeiten sind begrenzt | ✓ | – |
| Aufgabe ist offen formuliert | – | ✓ |
| Schritte ergeben sich erst aus dem Ergebnis vorheriger Schritte | – | ✓ |
| Vollständige Nachvollziehbarkeit und Vorhersagbarkeit wichtig | ✓ | – |
| Flexibilität und autonomes Handeln wichtig | – | ✓ |
Der Workflow Supervisor ist mächtig — aber weniger vorhersagbar als regelbasierte Muster. Für Prozesse mit regulatorischen Anforderungen (z. B. Rechnungsverarbeitung mit Buchungspflicht) ist eine State Machine mit expliziten Status-Übergängen die sicherere Wahl. Den Supervisor einsetzen wenn Flexibilität wichtiger ist als lückenlose Nachvollziehbarkeit.
Debugging-Tipps
History auswerten — bei unerwartetem Verhalten ist das history-Feld die erste Anlaufstelle. Es zeigt jede LLM-Entscheidung mit ihrer Begründung.
Workflows isoliert testen — bevor du Workflows in den Supervisor einbindest, teste sie einzeln. Der Supervisor kann nicht zuverlässig arbeiten wenn die Tools die er nutzt fehlerhaft sind.
Agent Goal präzisieren — wenn der Supervisor falsche Entscheidungen trifft, liegt es oft am zu vagen Agent Goal. Formuliere konkreter was er tun soll und was er nicht tun soll.
max_iterations anpassen — bei komplexen Multi-Step-Aufgaben kann es sein dass der Supervisor mehr Zyklen braucht als der Standardwert erlaubt. Erhöhe den Wert schrittweise und beobachte die Auswirkungen.